audio and computer clocks are not exact and can drift.
example of this effect: AudioQuest DragonFly, whose clock skews fast automatically
assume the computer clock is more accurate than the audio clock.
that means when converting audio events from computer time to audio time, a simple conversion is insufficient.
events should be benchmarked by the computer clock, and converted to audio time only at the last minute.
that means the audio thread does the conversion.



PaStreamCallbackFlags tells you when underrun happened. so as long as we assume the calibration for the 44100 Hz audio and the global system clock align, there should be no slippage.
so, I tested the two clocks, and they gradually drift out of sync. the audio clock is fast, so new events are late by the audio thread's accounting
that means the audio thread and computer time must constantly re-sync?
for me, it's because my AudioQuest DragonFly is retarded, and has a 44118 Hz clock.